Summer of 15614

We look at statistics from recent epochs of Medalla. If you haven’t, check out our first exploratory notebook on Medalla data.

Finding the declared client

We associate each validator index to a client among Lighthouse, Prysm, Nimbus, Teku and “undecided”. To do so, for each canonical block produced, we inspect the graffiti. We associate the block to a client whenever the name of the client features in the graffiti (with a case-insensitive search). When the first four characters of the graffiti are poap, we check the last character: when the character is “a”, “b”, “c”, “d” or “e”, we guess the client producing the block is (respectively) Prysm, Lighthouse, Teku, Nimbus or Lodestar. Due to the low prevalence of Lodestar blocks, we have decided to remove it from the analysis.

Since our analysis is carried over the 300 or so latest epochs, we assume that a validator index is using the latest recorded client obtained from a block produced by that validator. When we compare the performance of a client at the beginning of the testnet (between slots 0 and 30,000), we recompute the likeliest client as the earliest recorded client used by a validator index.

Additionally, we make available a list associating the validator indices to their recognised client here. If you notice any discrepancy between this list and your own observations, please let me know on Twitter or Discord.

Attester duties fulfilled by validators with declared clients

We plot the latest epochs on the x-axis and align validators on the y-axis. Green cells show epochs where the validator attested, and red cells where they didn’t. Note that the client is obtained from the graffiti (either from the POAP tag or if the client name is in the graffiti).

Epoch 20,000 to 20,099

A moment in time, between 2020-11-01 10:20:08 and 2020-11-01 20:53:44.

Epoch 20,100 to 20,199

A moment in time, between 2020-11-01 21:00:08 and 2020-11-02 07:33:44.

Epoch 20,200 to 20,299

A moment in time, between 2020-11-02 07:40:08 and 2020-11-02 18:13:44.

Epoch 20,300 to 20,399

A moment in time, between 2020-11-02 18:20:08 and 2020-11-03 04:53:44.

Potential staking activity

If we wanted to, could we finalise? We look at the attesting record of validators between epochs 20300 and 20400. We define a validator as potentially active if the validator attested at least once during this period and their exit epoch is beyond epoch 20400. Active validators are validators who are still expected to attest – regardless of whether they were recognised as potentially active or not. They are detected as validators whose exit epoch is beyond 20400.

We first measure the potential weight, the sum of effective balances of all potentially active validators.

We then look at the active weight, the sum of effective balances of all active validators.

Getting the ratio between the two, we can get an idea of the highest participation rate we can expect.

Uh oh. We need that number to get above 66.66%.

Subset and clashing aggregations per client

Here we focus our data collection on two periods:

Between slot 0 and slot 30,000.
Between slot 590,000 and slot 610,000.

We first look at the number of aggregates included per declared client at both times.

This appears to tally up with Michael Sproul’s claim over at the Eth R&D Discord:

As far as I can tell [Lighthouse] seems to be good at not including junk on chain, and I regularly see my validators proposing blocks that aren’t full, see e.g. https://beaconcha.in/blocks?q=I%20stay%20noided I’d love someone to confirm my hunch though

Subset aggregates are aggregates included in a block which are fully covered by another aggregate included in the same block. Namely, when aggregate 1 has attesting indices \(I\) and aggregate 2 has attesting indices \(J\), aggregate 1 is a subset aggregate when \(I \subset J\). How often do these aggregates show up in various client blocks?

Since we’ve seen varying average number of included aggregates per client, we can normalise by looking at the average percentage of subset aggregates included in the blocks.

Progress was made over time! To repeat: subset aggregates bring zero extra information on validator votes, and thus can (and should) be dropped entirely when recognised as such.

Head and target correctness per client

We now look at how correct the clients are at finding the target of the FFG vote and the head of the chain according to the LMD-GHOST fork choice rule, again between epochs 20000 and 24000 (slot 640000 to slot 768031).

Gaps between blocks

We look at the gap (in slots) between two consecutive blocks.

The longer the gap is, the more attestations we expect the next block to carry, as evidenced by the boxplots above. The thick line is the median number of attestations included, with the top and bottom ends of the box representing respectively the 25th and 75th quantiles.